Bit Stream Switching In Lossy Network

ABSTRACT

Coding and decoding techniques are disclosed in which a plurality of coding parameter sets is transmitted between an encoder and a decoder, each of which is distinguishable from the others by a respective identifier. When a new frame of video is to be coded, an encoder may identify a coding parameter set to be applied during coding, it may code the new frame according to the identified coding parameter set, and it may transmit the coded frame to the decoder along with an identifier of the coding parameter set used during the coding. A plurality of coding parameter sets is persistent at an encoder and the decoder simultaneously.

BACKGROUND

The present disclosure relates to video coding systems and relatedprotocols.

Many modern electronic devices support video coding protocols.Implementations vary but, typically, a first device captures video dataat a local location and applies data compression operations upon thevideo data to transmit the video data to a second device over abandwidth-limited channel. The second device inverts coding operationsthat were applied by the first device to generate recovered video datathat can be displayed locally.

Oftentimes, transmission errors can arise that cause loss of data whenthe coded video data is delivered to the second device. Real-time videocommunication applications often use lossy network protocol stacks suchas the Real-time Transport Protocol, the User Datagram Protocol and theInternet Protocol (RTP/UDP/IP). To transmit coded video, variousportions of a coded bit stream (such as an HEVC coded bit stream) may beallocated to transmission units (perhaps packets), which are formattedfor transmission and transmitted from the first device to the channel.Transmission errors may arise that cause some packets to be lost intransmission and, as a consequence, cause some elements of the coded bitstream to exhibit corruption. Thus, some syntactic elements of the codedbit stream, such as coded frames or administrative data, might not berecovered from the transmission data that is received at the seconddevice.

Some transmission errors may be more significant than others due to datadependencies that are created by a coding protocol. For example, when atransmission error arises with respect to a pixel block in a singleframe, the transmission error may not have a significant impact oncoding performance particularly if other content of the video sessiondoes not rely on the corrupted pixel block. If a transmission errorarises with respect to coding elements on which a large number of othercoding elements arise, the transmission error can cause loss of asignificant amount of data.

The inventors have identified sequence parameter datasets (SPSs) andpicture parameter datasets (PPSs) as coding elements that can give riseto large losses of data in coding applications. They have identified aneed to develop coding protocols to protect against coding corruptionevents that can occur due to loss of SPS and/or PPS data intransmission.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a video coding system according to an embodiment ofthe present disclosure.

FIG. 2 illustrates a method according to an embodiment of the presentdisclosure.

FIG. 3 illustrates a coding protocol according to another embodiment ofthe present disclosure.

FIG. 4 is a flow diagram illustrating a method of operation according toan embodiment of the present disclosure.

FIG. 5 illustrates a method according to another embodiment of thepresent disclosure.

FIG. 6 illustrates an exemplary coding session that may be createdaccording to an embodiment of the present disclosure.

FIG. 7 illustrates an exemplary coding session that may be createdanother embodiment of the present disclosure.

FIG. 8 is a functional block diagram of source and sink terminalsaccording to an embodiment of the present disclosure.

DETAILED DESCRIPTION

Embodiments of the present disclosure provide coding and decodingtechniques in which a plurality of coding parameter sets is transmittedbetween an encoder and a decoder, each of which is distinguishable fromthe others by a respective identifier. When a new frame of video is tobe coded, an encoder may identify a coding parameter set to be appliedduring coding, it may code the new frame according to the identifiedcoding parameter set, and it may transmit the coded frame to the decoderalong with an identifier of the coding parameter set used during thecoding. A plurality of coding parameter sets is persistent at an encoderand the decoder simultaneously.

FIG. 1 illustrates a video coding system 100 according to an embodimentof the present disclosure. The system 100 may include a pair ofterminals 110, 120 provided in mutual communication by a network 130.For unidirectional transmission of video, the first terminal 110 maycode video data at a local location for transmission to the otherterminal 120 via the network 130. The second terminal 120 may receivethe coded video data of the first terminal 110 from the network 150,decode the coded data and display or store the recovered video datalocally at the terminal 120. Coding and decoding operations may operateaccording to a predetermined coding protocol such as an MPEG codingstandard, AVC, HEVC and the like. Unidirectional data transmission iscommon in media serving applications and the like. For convenience, thefirst terminal 110 is called a “source” and the second terminal 120 iscalled a sink to distinguish their respective roles in unidirectionaldata transmission.

The embodiments described herein also find application in bidirectionalexchange of coded video that may occur, for example, duringvideoconferencing. For bidirectional transmission of data, each terminal110, 120 may code video data captured at a local location fortransmission to the other terminal via the network 130. Each terminal110, 120 also may receive the coded video data transmitted by the otherterminal, may decode the coded data and may display or store therecovered video data locally at the terminal 110, 120. In bidirectionalexchanges (not shown in FIG. 1), both terminals would operate as a“source” and a “sink.”

In FIG. 1, the terminals 110-120 are illustrated as servers and smartphones but the principles of the present disclosure are not so limited.Embodiments of the present disclosure find application with personalcomputers, laptop computers, tablet computers, media players and/ordedicated video conferencing equipment. The network 130 represents anynumber of networks that convey coded video data among the terminals110-120, including for example wireline and/or wireless communicationnetworks. The communication network 150 may exchange data incircuit-switched and/or packet-switched channels. Representativenetworks include telecommunications networks, local area networks, widearea networks and/or the Internet. For the purposes of the presentdiscussion, the architecture and topology of the network 130 isimmaterial to the operation of the present disclosure unless explainedherein below.

FIG. 2 illustrates a method 200 according to an embodiment of thepresent disclosure, which may occur when a coding event causes revisionof SPS or PPS data (“configuration” data, for convenience). Thus, themethod 200 may be invoked when the source terminal is coding video andtransmitting the coded video to a sink terminal (msg. 210) and thesource terminal determines that coding parameters of the coding sessionmust change (box 220). According to the method 200, the source terminalmay transmit new configuration data to the sink terminal in a secondchannel defined by the network 130 (FIG. 1) (box 230), whereupon thesink terminal stores the new configuration data locally (box 240).

The source terminal may transmit the new configuration data in a channelof the network 130 (shown as “Ch. 2” in FIG. 2) that is different fromthe channel (“Ch. 1”) that is used to transmit coded video data to thesink terminal in msg. 210. The second channel Ch. 2 may be provisionedto have higher reliability within the network 130 than the first channelCh. 1, for example, by allocating a relatively higher quality of serviceto the second channel Ch. 2. The second channel Ch. 2, for example, mayoperate according to a protocol that requires the sink terminal totransmit an acknowledgment message 245 to the source terminal uponreceipt of the configuration message 230 or upon successful storage ofthe new configuration data in box 240. The source terminal may awaitreception of the acknowledgment (box 250) and, once the acknowledgementis received, may code video data according to the new configuration andtransmit the coded video data to the sink terminal (box 260).

If, at box 250, the acknowledgement message is not received within anexpected amount of time after transmitting the new configuration data inthe second channel Ch. 2, the source terminal may retransmit parametersof the new configuration in a second message transmitted in the secondchannel Ch. 2 (box 230). The source terminal may continue to transmitand retransmit new configuration data in the second channel untilsuccessful transmission is acknowledged. During this time, the sourceterminal may continue to code video data according to the former set ofconfiguration parameters until successful transmission is acknowledged.

In other embodiments, rather than providing for an explicitacknowledgment message, the second channel Ch. 2 may provide higherquality of service by providing relatively higher performance intransmission delay, message loss probability and/or bit error rate ascompared to the first channel Ch. 1.

Configuration parameter messages may carry information that define oneor more of the following characteristics of coded frames: frame size andresolution, frame rate, frame format (e.g., PAL vs. SECAM), entropiccodes, profile/level, chroma format, bit-depth, scaling-matrix, numberof reference frames, frame cropping parameters, weighted prediction,number of slice groups, chroma quantization paramger (QP) offset, and/ordeblocking filter control.

FIG. 3 illustrates a coding protocol 300 according to another embodimentof the present disclosure. According to the protocol, different sets ofcoding parameters may have parameter identifiers assigned to them, whichmay provide a basis for identifying transmission errors involving suchparameters. FIG. 3 illustrates two exemplary bit streams 310 and 320. Inthis example, the bit streams are members of a common video codingsession but have different coding parameters defined for them. Theparameters may be defined, for example, in SPS and/or PPS fields of agoverning coding protocol.

The first bit stream 310 is illustrated has having a parameter header312, a plurality of coded video frames 314.1-314.N. Similarly, thesecond bit stream 320 is illustrated as having its own parameter header322, a plurality of coded videos frames 324.1-324.M. The parameterheaders 312, 322 each may contain data (not shown) defining parametersfor decoding the frames 314.1-314.N, 324.1-324.M of their respective bitstreams 310, 320.

In an embodiment, the parameter headers 312, 322 each may have anidentifier field 313, 323 that contains an identifier that distinguishesthe parameter header 312 from other parameter headers 322 of the videocoding session. Coded frames within a common bit stream as theirrespective parameter header also may contain identifiers that associatethe frames with their parameter header. Thus frames 314.1-314.N maycontain an identifier that associates those frames with the identifier313 of parameter header 312 and frames 324.1-324.M may contain anidentifier that associates these frames with the identifier 323 ofparameter header 322.

FIG. 4 is a flow diagram illustrating a method of operation according toan embodiment of the present disclosure. The flow diagram illustratessignal flow that may extend between a source terminal and a sinkterminal and operations that may be performed by the source and/or sinkterminal in response to such signal flow.

The method 400 may begin with the source terminal transmitting a message410 to a sink terminal that includes parameters of a new bit streamconfiguration and also a header ID. In response to the message 410, thesink terminal may store those parameters locally at the terminal, alongwith the header ID (box 415). Thereafter, the source terminal may codenew video according to the current bit stream configuration (box 420)and transmit coded video that was coded according to the bit streamconfiguration (msg. 425). The operations represented by box 420 andmessage 425 may continue as long as the source terminal determines tocode video according to a common set of coding parameters (box 430).When the source terminal determines to code video according to a new setof coding parameters, the source terminal may transmit a new message 410identifying the new coding parameters, along with a new header ID.

At the sink terminal, when a new frame of coded video data is received(msg. 425), the sink terminal may determine whether the coded frame hasan ID that matches a most-recently received header ID (box 435). If so,the sink terminal may decode the coded frame using parameters that werestored in box 415 (box 440). If not, then the sink terminal maydetermine that an error condition exists because configurationparameters necessary to decode the frame are missing (box 445). The sinkterminal may send a message to the source terminal requesting missingconfiguration parameters (msg. 450). In response, the source terminalmay sent a new message 445 that provides configuration parameters to beused during decode of the coded frame, along with its header ID. Thesink terminal may store the configuration parameters locally at theterminal with its header ID (box 460) and may decode the coded frame(box 440).

FIG. 5 illustrates a method 500 according to another embodiment of thepresent disclosure. According to the method 500, a source terminal maytransmit configuration parameters associated with a predetermined number(N) of different bit streams in an early portion of a video codingsession, for example, before any coded video data is transmitted in achannel (msgs. 512, 514, 516). The configuration parameters may bestored locally by a sink terminal (box 520). Thereafter, as new videodata is presented for coding, the source terminal may select which ofthe bit stream configurations is best suited for coding the new video(box 530) and may code the video data by that bit stream configuration(box 540). The source terminal may transmit the coded video to the sinkterminal, along with an identifier of the bit stream configuration thatwas used for coding (msg. 550). The sink terminal may decode the codedvideo according to configuration parameters that are identified by theidentifier provided in the coded video (box 560).

The foregoing operations allow a source terminal to define apredetermined number of coding configurations at the onset of a videocoding session, then toggle among the coding configurations as codingcircumstances dictate. To switch among coding configurations in themidst of a coding session, the source terminal may simply apply codingparameters from a newly selected configuration and supply coded videodata to the sink terminal along with the ID that identifies the codingparameters.

FIG. 6 illustrates an exemplary coding session that may be createdaccording to the embodiment of FIG. 5. FIG. 6 illustrates a preamblesection of a video coding session that includes a plurality oftransmitted configuration parameter sets 612, 614, 616, each havingtheir own coding parameter data and identifiers. Following the preamble610 section, the session may include a plurality of coded frames622-636. Each coded frame may include an identifier that relates theframe to the configuration parameter set that was previouslytransmitted. For example, frames 622-624 and 630-632 each may includeidentifiers that relate those frames to configuration parameter set 612.Frames 626-628 may include identifiers that relate those frames toconfiguration parameter set 614 and frames 634-636 may includeidentifiers that relate those frames to configuration parameter set 616.

In an embodiment, a source terminal may supplement the set of codingparameters that it uses during coding throughout the course of a codingsession. For example, when receiving new video data, as a sourceterminal estimates a coding configuration for use to code the frame, thesource terminal may determine whether to supplement the sets of codingconfiguration parameters that have been transmitted already during thevideo coding session (FIG. 5, box 570). If the source terminaldetermines to supplement the set of coding parameters, the sourceterminal may transmit a new message 580 to the sink terminal, providinga new set of configuration parameters along with a new ID. The sinkterminal may store the new configuration parameter set locally, alongwith its identifiers (box 590). Thereafter, when the source terminalcodes video data and the sink terminal decodes it, the coding anddecoding may be performed with reference to the supplementedconfiguration parameter set identified in message 580.

FIG. 6 also illustrates exemplary signaling that supplements the codingparameter sets in the midst of a coding session. In this example,following transmission of coded frame 626, a new configuration parameterset 618 is shown as being transmitted, which includes a new identifier.The next transmitted coded frame 638 may be coded with reference to thenew coding parameter set 618.

In one embodiment, it may be efficient to provide configurationparameters only on an as needed basis, when a source terminal determinesto supplement coding parameters. In such an embodiment, rather thantransmit a plurality of configuration parameters at the beginning of acoding session, it is sufficient to transmit a single configurationparameter set at the beginning of a session (N=1 in FIG. 5) and transmitcoded video data according to that first configuration parameter set.Thereafter, the source terminal may expand the number of configurationparameters sets as it determines to add configuration parameter sets.Thus, the size of a preamble (FIG. 6) may be minimized, whichcontributes to reduced latency because coded frame data may transmittedto a sink terminal without undue delay.

FIG. 7 illustrates such an embodiment. In this embodiment, a singleconfiguration parameter set 712 is transmitted, which is sufficient todefine coding parameters of a first frame 722 to be coded. In theexample of FIG. 7, the configuration parameter set 712 is sufficient forcoding of a plurality of frames 722-724. Thereafter, a new configurationparameter set 714 is created, which is sufficient to code frames726-728. After transmission of coded frame 728, frames 730-732 are shownhaving been coded with respect to the first configuration parameter set712; no new configuration parameter set 712 is transmitted betweenframes 728 and 730. New configuration parameter sets 716 and 718 areadded as circumstances warrant, which in this example provide bases forcoding frames 734-736 and 738, respectively.

Returning to FIG. 5, the principles of the embodiment disclosed alsoaccommodate features described in the foregoing figures. For example, asink terminal may transmit acknowledgement messages 525, 595 when newconfiguration parameter sets are stored successfully at the sinkterminal. And, although not illustrated in FIG. 5, a sink terminal maycorrelate identifiers from received frames to the identifiers of theparameter sets that it stores locally; if a sink terminal determinesthat it does not store a coding parameter set that corresponds to anidentifier received in a coded frame, the sink terminal may request thecoding parameter set from the source terminal (message not shown). Inanother embodiment, configuration parameter sets may be transmitted in alogical channel of a communication network that is provisioned to havereliability than channel(s) provided for transmission of coded videodata.

In another embodiment, the source and sink terminal may operateaccording to a protocol that limits a number of concurrently persistentcoding parameter sets to a predetermined number (say, 32 codingparameter sets). Over time, a source terminal may transmit new codingparameter sets to a sink terminal. When a new coding parameter set isgenerated that exceeds the maximum number of persistent sets, a sourceterminal may disqualify an older coding parameter set from further useand transmit the new coding parameter set to the sink terminal. Thedisqualified coding parameter set may be identified expressly in a codedbit stream or, alternatively, it may be inferred from operationalparameter of the video coding session. For example, the disqualifiedcoding parameter set may be identified as the coding parameter set thatis oldest, as the coding parameter set that is least-recently used atthe time of disqualification or on some other basis. In anotherimplementation, a new coding parameter data set may re-use an identifierthat belongs to a disqualified data set; such an embodiment may requirea sink terminal to acknowledge reception of the new coding parameter setbefore coding data under the identifier to guard against errorconditions that otherwise might arise if transmission of the new codingparameter set encountered an error.

In another embodiment, the parameter set IDs (SPS_ID, PPS_ID forexample) may be jointly selected to represent certain parameter valuesof interest, like resolution/color format/bit-depth/etc, as a way forerror resilience. When decoder receives a coded frame, it may extractthe referred parameter sets, derive the target parameter values from theparameter set IDs, and check against the actual parameter values in theparameter sets. As an example, SPS_ID and PPS_ID may be selected suchthat (SPS_ID*256+PPS_ID) represent the video resolution in number ofmacroblocks. This same information can also be calculated from theparameter sets elements. By comparing these, the video decoder will beable to detect potential wrong parameter sets being used during thedecoding. When such an error condition is detected, the decoder mayrecover from the error condition by requesting retransmission of theparameter set.

To further help the video decoder with the capability of detecting wrongparameter sets being used, each coded frame may optionally choose toexplicitly specify all parameter set IDs. Modern coding protocols, forexample, H.264 and HEVC, only allow PPS_ID to be specified in eachframe.

FIG. 8 is a functional block diagram of source and sink terminals 810,850 that operate according to an embodiment of the present disclosure. Asource terminal 810 may include a video source 815, a preprocessor 820,a video encoder 825, a transmitter 830 and a controller 835. The videosource 815 may generate a video sequence for coding. The preprocessor820 may perform various processing operations that condition the inputsignal for coding. The encoder 825 may perform data compressionoperations to reduce the bitrate of the video sequence output from thepreprocessor 820. The transmitter 830 may transmit coded video data toanother terminal 850 via a channel 845 provided by a network. Thecontroller 835 may coordinate operation of the source terminal 810 as itperforms these functions.

Typical video sources 815 include image capture systems, such ascameras, that generate video from locally-captured image information.They also may include applications that execute on the source terminal810 and generate image information to be exchanged with a far-endterminal 850. Alternatively, the video source 815 may include storagedevices (not shown) in which video may be stored, e.g., the video wasgenerated at some time prior to the onset of a coding session. Thus,source video sequences may represent naturally-occurring image contentor synthetically-generated image content (e.g., computer generatedvideo), as application needs warrant. The video source also may providethe source video to other components within the source terminal 810 suchas a display (path not shown).

As indicated, the preprocessor 820 may perform video processingoperations upon the camera video data to improve quality of the videodata or to condition the video data for coding. The preprocessor 820also may perform analytical operations on the video that it receivesfrom the video source 815 to determine, for example, a size of thevideo, frame rate of the data, rates of change of content within thevideo, and the like. In response to analytical operations, thecontroller may determine that coding configuration of a video codingsession must change, which may cause it to alter and, as discussedhereinabove, expand a set of configuration parameter sets at work in thevideo coding session. The preprocessor may alter video characteristics,particularly frame rate and/or frame size, as may be needed to tailorcoded video to parameters defined in a selected coding parameter sets.Optionally, the preprocessor 820 may perform other processes to improvequality of the video data such as motion stabilization and/or filtering.Filtering operations may include spatial filtering, temporal filtering,and/or noise detection and removal.

The encoder 825 may code frames of video data to reduce bandwidth of thesource video and meet the target bitrate. In an embodiment, the encoder825 may perform content prediction and coding.

Prediction and coding operations may reduce the bandwidth of the videosequence by exploiting redundancies in the source video's content. Forexample, coding may use content of one or more previously-coded“reference frames” to predict content for a new frame to be coded. Suchcoding may identify the reference frame(s) as a source of prediction inthe coded video data and may provide supplementary “residual” data toimprove image quality obtained by the prediction. Coding may operateaccording to any of a number of different coding protocols, including,for example, MPEG-4, H.263, H.264 and/or H.265. Such coding operationstypically involve executing a transform on pixel data to another datadomain as by a discrete cosine transform or a wavelet transform, forexample. Transform coefficients further may be quantized by a variablequantization parameter and entropy coding. Each protocol defines its ownbasis for parsing input data into pixel blocks prior to prediction andcoding. The principles of the present disclosure may be usedcooperatively with these approaches.

The coding operations may include a local decoding of coded referenceframe data (not shown). Many predictive coding operations are lossyoperations, which causes decoded video data to vary from the sourcevideo data in some manner. By decoding the coded reference frames, thesource terminal 810 stores a copy of the reference frames as they willbe recovered by the sink terminal 850.

The transmitter 830 may format the coded video data for transmission toanother terminal. Again, the coding protocols typically define a syntaxfor exchange of video data among the different terminals. Additionally,the transmitter 830 may package the coded video data into packets orother data constructs as may be required by the network. Once thetransmitter 830 packages the coded video data appropriately, it mayrelease the coded video data to the network 130 (FIG. 1).

The transmitter 830 may estimate periodically an amount of bandwidththat is available within the network 130 (FIG. 1) for transmission ofcoded video to the other terminal 850. The transmitter 830 may estimatethis bandwidth level, for example, from indications of bit error rateand negative acknowledgements that it receives from the network 130(FIG. 1) or from the sink terminal 850.

FIG. 8 also illustrates functional units of a sink terminal 850 thatdecodes coded video data according to an embodiment of the presentdisclosure. The terminal 850 may include a receiver 855, a decoder 860,a post-processor 865, a video sink 870 and a controller 875. Thereceiver 855 may receive coded video data from the channel 845 andprovide it to the decoder 860. The decoder 860 may invert codingoperations applied by the first terminal's encoder 825 and may generaterecovered video data therefrom. The post-processor 865 may performsignal conditioning operations on the recovered video data from thedecoder 860, including dynamic range mapping as discussed below. Thevideo sink 870 may render the recovered video data. The controller 875may manage operations of the sink terminal 850.

As indicated, the receiver 855 may receive coded video data from achannel 845. The coded video data may be included with channel datarepresenting other content, such as coded audio data and other metadata.The receiver 855 may parse the channel data into its constituent datastreams and may pass the data streams to respective decoders (notshown), including the decoder 860. The receiver 855 may identifytransmission errors in the coded video data that it receives from thechannel 845 and, in response, may send error notification messages tothe transmitter 830 via a return path in the channel 845. Suchtransmission errors may include identification of missing configurationparameter sets, which may be identified by the decoder 860 and/orcontroller 875.

The decoder 860 may generate recovered video data from the coded videodata. The decoder 860 may perform prediction and decoding processes. Forexample, such processes may include entropy decoding, re-quantizationand inverse transform operations that may have been applied by theencoder 825. The decoder 860 may build a reference picture cache tostore recovered video data of the reference frames. Prediction processesmay retrieve data from the reference picture cache to use for predictivedecoding operations for later-received coded frames. The coded videodata may include motion vectors or other identifiers that identifylocations within previously-stored reference frames that are predictionreferences for subsequently-received coded video data. Decodingoperations may operate according to the coding protocol applied by theencoder 825 and may comply with MPEG-4, H.263, H.264 and/or HEVC.

The post-processor 865 may condition recovered frame data for rendering.As part of its operation, the post-processor 865 may perform dynamicrange mapping as discussed hereinbelow. Optionally, the post-processor865 may perform other filtering operations to improve image quality ofthe recovered video data.

The video sink 870 represents units within the sink terminal 850 thatmay consume recovered video data. In an embodiment, the video sink 870may be a display device. In other embodiments, however, the video sink870 may be provided by applications that execute on the sink terminal850 that consume video data. Such applications may include, for example,video games and video authoring applications (e.g., editors).

FIG. 8 illustrates functional units that may be provided to supportunidirectional transmission of video from a source terminal 810 to asink terminal 850. In many video coding applications, bidirectionaltransmission of video may be warranted. In such implementations, eachterminal 810, 850 would operate both as a source terminal and a sinkterminal. The principles of the present disclosure may accommodate suchapplications by replicating the functional units 815-835 within thesecond terminal 850 and replicating the functional units 855-875 withinthe first terminal 810. Such functional units are not illustrated inFIG. 8 for convenience.

The foregoing discussion has described operation of the embodiments ofthe present disclosure in the context of source terminals, sinkterminals, coders and decoders. Commonly, such devices are provided aselectronic devices. Encoders, for example, can be embodied in integratedcircuits, such as application specific integrated circuits, fieldprogrammable gate arrays and/or digital signal processors.Alternatively, they can be embodied in computer programs that execute onpersonal computers, notebook or tablet computers or computer servers;such programs are stored in memory systems and executed by processors ofsuch devices. Similarly, decoders can be embodied in integratedcircuits, such as application specific integrated circuits, fieldprogrammable gate arrays and/or digital signal processors, or they canbe embodied in computer programs that execute on personal computers,notebook computers or computer servers. Decoders commonly are packagedin consumer electronic devices, such as gaming systems, smartphones, DVDplayers, portable media players and the like, and they also can bepackaged in consumer software applications such as video games,browser-based media players and the like. The principles of the presentdisclosure find application with all such devices.

Several embodiments of the disclosure are specifically illustratedand/or described herein. However, it will be appreciated thatmodifications and variations of the disclosure are covered by the aboveteachings and within the purview of the appended claims withoutdeparting from the spirit and intended scope of the disclosure.

We claim:
 1. A coding method, comprising: transmitting a plurality ofcoding parameter sets to a decoder, each coding parameter set having arespective identifier; for a new frame of video to be coded, identifyinga coding parameter set of the plurality of coding parameter sets to beapplied during coding, coding the new frame according to the identifiedcoding parameter set, and transmitting the coded frame to the decoderalong with an identifier of the coding parameter set used during thecoding, wherein persistence of at least two coding parameter sets at anencoder and the decoder overlaps in time at least partially.
 2. Thecoding method of claim 1, wherein the plurality of coding parameter setsare transmitted in a preamble portion of a video coding session beforetransmission of a first coded frame.
 3. The coding method of claim 1,wherein one of the plurality of coding parameter sets is transmitted ina middle portion of a video coding session after transmission of a firstcoded frame.
 4. The coding method of claim 1, wherein: the identifying,coding and transmitting are performed anew for each of a plurality ofnew frames, and when successive coded frames are coded using differentcoding parameter sets, the successive coded frames are transmitted tothe decoder without transmission of a coding parameter set between them.5. The coding method of claim 1, further comprising: generating a newcoding parameter set; determining whether a number of persistent codingparameter sets exceeds a threshold, and in response to determining thatthe threshold is exceeded: disqualifying an older coding parameter set;and transmitting the new parameter set to the decoder.
 6. The codingmethod of claim 1, further comprising, responsive to a request from thedecoder for a missing coding parameter set, retransmitting the missingcoding parameter set to the decoder.
 7. The coding method of claim 1,wherein the identifying and coding are limited to coding parameter setsthat are acknowledged by the decoder.
 8. The coding method of claim 1,wherein the coding parameter sets are transmitted in a logical channelhaving higher reliability than another logical channel in which thecoded frames are transmitted.
 9. The coding method of claim 1, whereinthe identifier has a value that is mathematically related to a parametercontained in the coding parameter set.
 10. Computer readable mediumstoring program instructions that, when executed by a processing device,cause the device to: transmit a plurality of coding parameter sets to adecoder, each coding parameter set having a respective identifier; for anew frame of video to be coded, identify a coding parameter set of theplurality of coding parameter sets to be applied during coding, code thenew frame according to the identified coding parameter set, and transmitthe coded frame to the decoder along with an identifier of the codingparameter set used during the coding, wherein persistence of at leasttwo coding parameter sets at an encoder and the decoder overlaps in timeat least partially.
 11. A video coding system, comprising: a memory forstorage of a plurality of coding parameter sets; a video coder; atransmitter, and a controller to control operation of the video coderand transmitter and to: cause the transmitter to transmit a plurality ofcoding parameter sets to a decoder, each coding parameter set having arespective identifier; for a new frame of video to be coded, identify acoding parameter set of the plurality of coding parameter sets to beapplied during coding, cause the coder to code the new frame accordingto the identified coding parameter set, and cause the transmitter totransmit the coded frame to the decoder along with an identifier of thecoding parameter set used during the coding; wherein persistence of atleast two coding parameter sets at an encoder and the decoder overlapsin time at least partially.
 12. A video decoding method, comprising:responsive to reception of a plurality of coding parameter sets from anencoder, storing the coding parameter sets in memory in association withidentifiers that distinguish the coding parameter sets from each other,responsive to reception of coded video data of a frame, identify acoding parameter set identifier from the coded frame data; decode thecoded frame data using parameters of the identified coding parameterset, wherein persistence of at least two coding parameter sets at anencoder and the decoder overlaps in time at least partially.
 13. Thedecoding method of claim 12, wherein the plurality of coding parametersets are received in a preamble portion of a video coding session beforereception of a first coded frame.
 14. The decoding method of claim 12,wherein one of the plurality of coding parameter sets is received in amiddle portion of a video coding session after reception of a firstcoded frame.
 15. The decoding method of claim 12, wherein, whensuccessive coded frames are coded using different coding parameter sets,the successive coded frames are received from the encoder withoutreception of a coding parameter set between them.
 16. The decodingmethod of claim 12, further comprising, when the identifying indicatesthat a coding parameter set is missing, transmitting a request for themissing coding parameter set to the encoder.
 17. The decoding method ofclaim 12, further comprising transmitting an acknowledgement of eachsuccessfully received coding parameter set.
 18. The decoding method ofclaim 12, further comprising, when the identifier has a value that ismathematically related to a parameter contained in the coding parameterset: comparing an identifier of a received frame with parameter valuesin its identified coding parameter set, and if comparison indicates thereceived frame's identifier does not align to the parameter according tothe mathematical relationship, generating an error condition.
 19. Avideo decoding method, comprising: responsive to reception of atransmission from an encoder identifying a new coding parameter set,storing the parameter set with an identifier received from the encoder;responsive to reception of coded frame data, comparing an identifier ofa coding parameter set provided with the coded frame data to identifiersof locally stored coding parameter sets, when a match is identified,decoding the coded frame data according to the locally-stored codingparameter set; and when no match is identified, requesting the codedparameter set from the encoder.
 20. The decoding method of claim 19,wherein a plurality of coding parameter sets are received in a preambleportion of a video coding session before reception of a first codedframe.
 21. The decoding method of claim 19, wherein one of the pluralityof coding parameter sets is received in a middle portion of a videocoding session after reception of a first coded frame.
 22. The decodingmethod of claim 19, further comprising, following storing of a receivedparameter set, transmitting an acknowledgement message to an encoder.